👋 Thanks for creating a PR!

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

For contributor use:

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

Thank you for your contribution to the Cosmos-SDK! 🚀

Is this signing proto3 encoded bytes? Signing should be on json bytes, proto bytes don't let you inspect data before signing them, as you can in the ledger app. The information encoded in fields is ambiguous when protobuf binary encoded. You can't even tell if a number you're signing is negative or positive. Enforcing a canonical JSON format as the blockchain signing standard helps signing tools (like ledger apps) stay intelligent. Even if say the ledger app doesn't know what the tx means, it can show all the field names and values for the signer to inspect, as an advanced option.

Signing options introduces more complexity in the SDK, and more surface area for attack.

Another example... batch-signing tools should operate on lines of JSON txs (or sign-docs) in a file. You want the file of batch of txs to be inspected and reviewed as a static representation, then you want the tool to sign each line.

Is there a discussion on why this is needed?

Is this signing proto3 encoded bytes? Signing should be on json bytes, proto bytes don't let you inspect data before signing them, as you can in the ledger app. The information encoded in fields is ambiguous when protobuf binary encoded. You can't even tell if a number you're signing is negative or positive. Enforcing a canonical JSON format as the blockchain signing standard helps signing tools (like ledger apps) stay intelligent. Even if say the ledger app doesn't know what the tx means, it can show all the field names and values for the signer to inspect, as an advanced option.

Signing options introduces more complexity in the SDK, and more surface area for attack.

Another example... batch-signing tools should operate on lines of JSON txs (or sign-docs) in a file. You want the file of batch of txs to be inspected and reviewed as a static representation, then you want the tool to sign each line.

Is there a discussion on why this is needed?

We had extensive, extensive discussions on github, discord and zoom to arrive at the current design. Please read through #6078 for context.

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.